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PERFORMANCE PROFILING TOOL 

Field of Invention 

The present invention relates to performance 
profiling and more particularly to profiling an 
application running on a target computer remotely. 

Background of the Invention 

Computers have proliferated into all aspects of 
society and increasingly form the backbone of large 
organisations . When a computer system fails to respond 
as intended, businesses are invariably unable to provide 
even the most basic of services. Money, reputation or 
even lives may be lost, dependant upon the criticality of 
the service, the outage time etc. 

In today's increasingly competitive market-place, 
quality is of the utmost concern. Users' expectations 
are high and thus the reliability of hardware/ software is 
especially important . Customers do not tolerate mistakes 
and the later a defect is discovered, the more costly it 
can prove to the manufacturer. 

Typically software developers implement a rigourous 
testing regime in order to ensure that a product or 
system is fully operational and consistently performs 
according to its functional specification, before it is 
made available to the public. Providing efficient code 
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is an important aspect of the testing lifecycle. Just as 
frustrating as software that doesn't execute as expected, 
is software with an unacceptably poor response time. 

Performance profiling tools permit developers to 
measure and display program performance. Profiling in 
the broadest sense means the ability to monitor and trace 
events that occur at run- time; to calculate the cost of 
these events; and to apportion this cost to specific 
program modules. Memory leakages, performance 
bottlenecks etc are common problems which have to be 
addressed. Discovering where a piece of software spends 
the majority of its processing time and how effectively 
it uses system resources, is vital for performance fine 
tuning . 

Recently, the Java programming language (Java is a 
trademark of Sun Microsystems Inc.) has risen to 
prominence. Java offers numerous advantages to 
developers. It is a platform- independent , 
object-orientated language, with client/server 
functionality. It is also a lightweight, dynamic 
language designed with security in mind. For all these 
reasons, an ever- increasing amount software is being 
written in Java. 

A Java program executes using a Java Virtual Machine 
(JVM) . This is central to many of the language's 
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advantageous features, including its portability, 
efficiency and security. The JVM emulates a system's 
hardware, by stepping through a program and carrying out 
each instruction contained therein. Thus, the JVM need 
only be ported once for each operating environment and 
then all applications running on top of the virtual 
machine may execute unchanged. Furthermore, the JVM 
creates a layer of abstraction between a computer and the 
software being run on it, hence providing greater 
protection against malicious viruses etc. 

With Java's growing popularity, performance 
profiling tools, which in particular monitor the 
performance of the JVM and applications running on top of 
it, have become an important issue. Sun Microsystems 
Java 2 software development kits (SDKs) support a 
performance profiling interface known as the Java Virtual 
Machine Profiling Interface (JVMPI) . This is an 
interface provided to external agents written in the 'C 
programming language which allows the agents to register 
with the JVM and receive notifications of events of 
interest to performance tools via this interface. 

The JVMPI represents a considerable advance over 
previous Java profiling solutions as it offers a 
standard, extendible interface, agreed through 
consultation with Java tools vendors and other companies 
such as IBM. It defines a general -purpose, portable means 
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for acquiring comprehensive profiling data. Typically, 
the different profiling tools will have varying aims and 
require different information. For example, one may 
merely dump profile data to a trace file, whilst another 
tool may process the data selectively and interactively, 
and present a more sophisticated view via a graphical 
user interface. Tool vendors may write to the JVMPI, 
rather than having to code custom-built hooks directly 
into the JVM itself. It allows them to access consistent 
interfaces and events on JVM implementations which have a 
JVMPI consistent with Sun's definition. Commercially 
available profiling tools include Jprobe from KL Group 
Inc., Canada and True Coverage from Compuware NuMega, 
America . 

Figure la is a high-level schematic diagram of the 
operation of a performance tool profiling the JVM using 
the JVMPI according to the prior art . A computer 10 runs 
a JVM 20. A second computer 3 0 runs a performance tool 
4 0 for profiling the JVM 20. It will, however, be 
appreciated that the performance tool 4 0 and the profiler 
agent 5 0 may run on the same computer (ie computer 10 or 
computer 30) . The performance tool communicates over a 
tool -specific wire protocol via arrow 1 with a profiler 
agent 50. The agent implements all the JVMPI interface 
functions it requires and has to deal with the event data 
it receives, passing information back to performance tool 
4 0 as required. The JVM calls this in order to enable 
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the agent to receive events (via arrow 2) from the JVM 
via the JVMPI 60 at run- time. Events can include heap 
allocation, thread start etc., and the agent then 
communicates such information to the performance tool 
(arrow 1) . On the basis of this, the tool can determine, 
for example, heavy memory allocation sites, unnecessary 
object retention, monitor contention etc. The agent 
sends controls and requests for more information to the 
JVM (arrow 3) also via the JVMPI. In order to enable 
this, the JVM implements a number of call-back functions. 
The agent may, for example, switch on or off notification 
of a specific event (via the EnableEvent and DisableEvent 
functions) in accordance with the requirements of the 
remote tool 40. The agent may also request notification 
of certain types of event such as HEAP_DUMP and MONITOR 
DUMP, via the RequestEvent function. 

Figure lb shows in more detail the operation a 
performance tool profiling the JVM according to the prior 
art. It should be read in conjunction with figure la. 
Appendix A shows the source code for a simple profiler 
agent provided by Sun Microsystems . The text may be 
cross-referenced with the code in order to aid 
comprehens ion . 

The JVM 2 0 is launched with the command 
"-XrunMyProf iler" , where "MyProfiler" is the profiler 
agent 50 (step 60) . The agent has an entry point 
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(method) JVM_Onload . By default the -Xrun command 
registers the JVM through this method in the agent 50. 
Before the agent can register to receive a particular 
event (via arrow 2) however, a function call interface 
must be obtained by issuing a GetEnv call on a JavaVM 
pointer (step 65) . This pointer forms part of the JVM 
environment and is responsible for retrieving a further 
pointer ( j vmpi_interf ace) to the JVMPI 60. The JVMPI 
facilitates the enablement, requesting and general 
processing of events using the Notif yevent ( ) and other 
known functions (eg EnableEvent, DisableEvent etc) . 
Additionally the GetEnv function verifies that the 
current version of the JVM is supported by the JVMPI. 
Only versions 1.2 and later of the Java Development Kit 

(JDK) are compatible. 

Once the j vmpi_interf ace pointer has been returned, 
the JVMPI is then initialized (step 70) . The JVMPI 
includes the Notif yEvent ( ) function which the JVM would 
normally invoke with each new event. However, in order 
for the profiler agent to receive the events rather than 
the profiler interface, it is necessary to redirect the 
pointer, and this is acheived via 

"j vmpi_interf ace- >Nof if yEvent =not if yEvent" . The agent 
code includes the notifyEvent function and this is now 
pointed to. 
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The profiler agent invokes an EnableEvent ( ) function 
via "JVMPI_Interface->EnableEvent ( ) " in order to instruct 
the JVM to communicate a given event to the notifyEvent 
function upon occurrence of that event (step 75) . Such 
5 events are then received by the profiler agent from the 

JVMPI (step 80) . For more information on the JVMPI 
functions, please see 

http: //www. ddj . com/articles/19 9 9/9909/9909k/990 9k.htm. 

10 One example of a basic, JVMPI compatible, profiling 

agent, is HPROF which is shipped with Java 2 SDK, 
Standard Edition, version 1.2 and later. It interacts 
with the JVMPI in order to provide the user with data 
either directly or through a profiling front-end (ie 

1^5 performance tool) . Note, the front -end may either be 

local to the JVM or on a remote machine. HPROF simply 
dumps data to a report file, permitting very little 
control of that data. This file can however be further 
processed by the performance tool . The file may again be 

3=2 0 local to the JVM or on a remote machine (typically, the 

machine upon which the performance tool is executing) . 

The JVMPI and the HPROF profiler are documented in 
more detail at the Sun Microsystems' website: 
25 http: //java. sun. com/products/ jdk/l . 2/docs/guide/jvmpi/jvm 

pi. html; and the IBM Corporation's Systems Journal entry 
at 
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ml. 

The implementation described above has a number of 
drawbacks . The presence of the JVMPI in a JVM on a 
computer requires the JVMPI profiling agent to reside on 
that computer in order to register and receive events for 
subsequent processing. This means that for each and 
every tool, the JVMPI agent 'C code must be ported to 
the target computer, compiled, debugged and shipped by 
the tool writer. In practice, this has meant that Java 2 
performance tools have not supported all the computer 
platforms which have JVMPI implementations - in just over 
a year after Java 2 launched in December 1998, only 
Windows NT and Solaris platforms have third party tools 
working with the Sun JVM. Support is not, for example, 
provided for many platforms such as OS/390 from IBM and 
it may be difficult to find the skills and machines to 
allow the tools vendors to implement their tools on all 
platforms. As Java becomes established as a major 
programming language, the availability of performance 
tools on both development and deployment computers 
becomes a prerequisite for business-critical 
applications . 

Furthermore, all performance tools perturb the 
performance characteristics of the system they are 
measuring, unless they are built in and cannot be 
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disabled. The events which the JVMPI is capable of 
generating that are of interest to performance tools, 
such as method entry and exit, occur very frequently and 
can accumulate high data volumes. Additionally, many 3rd 
party tools offer 'real time' visualization of Java 
performance data as it is being generated. If the 
computer being measured is the same one as is being used 
to display the data, the perturbation of the data can, 
once again, be considerable. 

The IBM Corporation recently announced the release 
of VisualAge Micro Edition. This provides an integrated 
development environment for building end- to- end embedded 
systems. In other words, it enables the development of 
applications connecting small, resource constrained 
devices, such as personal digital assistants (PDAs) and 
cell phones, to enterprise back-end systems over the 
Internet . 

VisualAge Micro Edition is shipped with a profiler 
for monitoring the performance of a JVM running within an 
embedded system, as well as applications executing on top 
of the virtual machine. This profiler can either sit 
directly on the embedded device or be run remotely from a 
development workstation. A remote setup has the 
advantage that the minimum of load is placed on the 
embedded device . 
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Figure 2 is a schematic diagram of such a remote 
profiler configuration. An embedded device 100 runs a 
JVM 110. A computer 130 runs a profiler agent 140. The 
JVM receives control commands from the agent and in 
return the agent receives events from the JVM, The agent 
communicates the information received from the JVM to a 
performance tool 150. 

Whilst the profiler agent communicates remotely with 
the JVM 110, it does so via a direct entry-point. In 
other words, the JVM 110 itself has been specially 
modified to support the Profiler Agent 140. The JVMPI 
and all of the advantages it provides have been dispensed 
with in this solution. Although the agent code does not 
have to be ported to the embedded device, it does have to 
be compiled and debugged by the tool writer in order to 
be compatible with the specific JVM implementation. For 
more information on VisualAge Micro Edition, please see 
http : / / www-4 . ibm . com/software/ad/embedded. 

It has been suggested to provide remote access for 
profiling agents via the JVMPI to achieve greater 
portability. Figure 3 shows the constituent parts of 
this proposal. A computer 207 runs a profiling agent 280 
which profiles a JVM 200 running on a second computer 
205. The JVM 200 sends events via a JVMPI 210 to a proxy 
220. Proxy 220 is 'C code and is responsible for 
receiving the profiling data generated by the JVM 200. 
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In order to communicate this to computer 207 and 
ultimately the profiling agent 280, the event flow has to 
re-enter Java via a second JVM 230. It does this using 
the Java Native Interface (JNI) 225. This re-entry is so 
that existing java mechanisms can be used to transport 
the events to the profiling agent running on computer 
207. Thus transparency can be achieved, this being the 
primary aim. The intention is to have the profiling 
agent write to the JVMPI interface, whilst being 
completely unaware as to whether it is running locally or 
remotely . 

In order to transmit events to the profiling agent 
there is a java proxy 235 running within JVM 230. This 
calls a remote method (java proxy) 2 65 running on 
computer 207 via a Remote Method Invocation (RMI) 
interface 255. Thus an existing protocol, Java Remote 
Method protocol (JRMP) , is used to communicate with 
computer 2 07. Remote Method (Java Proxy) 265 runs within 
a third JVM 260 and receives the events. As disclosed, 
these are then communicated via the JNI 22 6 to the 
profiling agent 285. Intelligent caching of data is 
built-in, in order to minimise the network traffic. 

In reality this scenario would not achieve its 
primary aim of transparency. The profiling agent would 
realise that the events it received from JVM 22 6 had 
indeed come from its local machine 205 rather than the 
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true originator, JVM 200. This is because JNI interface 
256 is presented to the profiling agent, rather than a 
JVMPI interface as should be the case. 

The unachieved original aim of transparency has 
forced some complex design issues highlighted above. 
Performance is also likely to be significantly impeded. 

Disclosure of the Invention 

Accordingly, the invention provides an apparatus for 
providing application execution data to a profiling agent 
on a remote system as requested by said agent, wherein a 
first application local to said apparatus generates said 
application execution data, said apparatus comprising: 
means for receiving a request via a network interface 
from said profiling agent for said application execution 
data; means, responsive to said request, for requesting 
said application execution data from said first 
application via a local interface; means for receiving 
said application execution data from the first 
application via said local interface; and means, 
responsive to receipt of said application execution data, 
for transmitting said application execution data to the 
profiling agent via said network interface. 

According to the preferred embodiment, the network 
interface exposes substantially all the functionality of 
the local interface to a profiling agent on a remote 
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system. Thus the profiling agent does not have to be 
ported to the machine on which the first application is 
executing, nor does it have to be tailored accordingly. 
Rather it is the apparatus that is configured once for a 
particular platform to enable it to communicate with the 
local interface to receive the application execution data 
from the first application via that local interface. 
Remote profiling agents have to be modified once only to 
support the network interface which can be standard 
across all platforms . They are then able to communicate 
with the apparatus and receive the application execution 
data from the first application. The profiling agents 
themselves need operate only on a single platform, 
thereby greatly simplifying the development and 
maintenance tasks for the tool vendors. Furthermore, a 
single profiling agent may be operated to work with 
application execution data from multiple machines, 
thereby providing easy access to comparative machine 
performance analysis. 

Preferably, the network interface further allows 
receipt of controls from the profiling agent and these 
are used to control the operation of the apparatus . 
Application execution data is received from the first 
application by the profiling agent either synchronously 
or asynchronously. At least one of the controls provides 
for selectively switching between these two modes . The 
synchronous mode can be used in problem determination 
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since it is possible to track the flow of application 
execution data more easily, whilst the asynchronous mode 
is more efficient in terms of network resources. 

Preferably, the controls are transmitted over a 
first connection, whilst the application execution data 
is transmitted over a second connection. Splitting the 
data flow in this way means that the transmittal of 
application execution data to the profiling agent does 
not interrupt the sending of controls and vice versa. 

According to the preferred embodiment, there is a 
buffer for storing the application execution data prior 
to transmission to the profiling agent. This enables the 
data to be batched for transmission asynchronously. It 
will be appreciated that the first application may 
generate a large amount of data and by sending this data 
in batches the network is not flooded. 

The application execution data generally includes 
events. Each buffered event is stored with a timestamp. 
This is used to ensure that the events are transmitted to 
the remote profiling agent in the order in which they 
were received from the first application. 

According to the preferred embodiment, at least one 
of the events is specified as requiring synchronous 
transmission. Synchronous events for example are those 
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to which the first application requires an immediate 
response from the profiling agent in order to prevent 
premature termination of that first application. Receipt 
of one of these events causes the buffer to be flushed 
and the apparatus to switch to synchronous mode. 

Typically when in asynchronous mode, the contents of 
the buffer are transmitted to the profiling agent once 
the buffer has reached a pre -determined threshold, or 
alternatively the profiling agent may specifically 
request the contents of the buffer. Furthermore, when 
the first application terminates the contents of the 
buffer are also transmitted to the remote profiling 
agent. Note, the application execution data is 
preferably compressed prior to transmitting it to the 
profiling agent to reduce network bandwidth. 

According to the preferred embodiment, the local 
interface is a java virtual machine profiling interface 
(JVMPI) and the first application is a java virtual 
machine (JVM) . A second application executes on top of 
the JVM and causes it to generate the application 
execution data. 

Brief Description of the Drawings 

A preferred embodiment of the present invention will 
now be described, by way of example only, and with 
reference to the following drawings: 
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Figure la is a schematic diagram of the operation of 
a performance tool profiling the JVM using the JVMPI 
according to the prior art ; 

Figure lb shows in more detail the operation of a 
performance tool profiling the JVM according to the prior 
art . 

Figure 2 illustrates a prior art remote profiler 
configuration; 

Figure 3 shows a remote profiling solution using a 
JVMPI according to the prior art ; 

Figure 4 is a high-level schematic diagram of the 
operation of a preferred embodiment of the present 
invention; 

Figure 5a shows the operation of the universal JVMPI 
adapter (UJA) according to a preferred embodiment of the 
present invention; 

Figure 5b shows the operation of the profiler agent 
according to a preferred embodiment of the present 
invention; 

Figure 6a is a flowchart of the data exchange that 
takes place between the UJA and the profiler agent 
according to a preferred embodiment ; 

Figure 6b shows the layout of a control data packet 
according to a preferred embodiment of the present 
invention; and 

Figure 6c shows the layout of a response data packet 
according to a preferred embodiment of the present 
invention. 
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Please note, figures 4 to 6 may be read in 
conjunction with appendix B which provides a pseudo code 
representation of the functionality supported by both the 
UJA and the remote profiler agent. 

Description of the Preferred Embodiments 

With reference to figure 4, a computer 310 runs a 
JVM 320. A second computer 330 runs a performance tool 
34 0 for receiving profiling data relating to JVM 3 20 and 
any applications running on top of the JVM (not shown) 
from a main profiler or profiling agent thread (PA) 354. 
The profiler agent thread runs on computer 33 0 and so 
profiles the JVM remotely. Computer 310 also runs a 
JVMPI 3 60 and a Universal JVMPI Adapter main thread (UJA) 
350. The UJA registers with the JVM through the JVMPI 
and acts as a local proxy to the remote profiler agent. 
The UJA communicates through a TCP/IP socket to the 
profiler agent, and through the JVMPI to the JVM being 
measured. In the preferred embodiment communication 
takes place through an agreed port, although other 
discovery protocols could be used. 

The profiler agent thread transmits controls (arrow 
11a) via a first connection to the UJA and in return 
receives responses (arrow 12) and data (arrow 15) over 
that same connection. As a direct result of these 
controls the UJA may query the JVM for specific 
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information (arrow lib) , or indeed the local hardware etc 
(not shown) . 

Once the remote profiler has successfully 
established the first connection for UJA controls etc to 
be transmitted over, a second connection is set-up for 
the transmission of JVMPI data (ie events) from the UJA 
to the remote profiling agent. A buffer management 
thread 3 65 is spawned on the target computer 310 and a 
profiling buffer receiving thread 356 on computer 330. 
The second connection is then established between these 
two threads . 

Specific event types are requested over the first 
connection 11a, lib and returned to the main UJA thread. 
Events are then transmitted in the reverse direction to 
the UJA and interface functions are processed to enable 
this and to enable the remote profiler agent to gather 
additional information. (Note, according to the 
preferred embodiment, the interface functions defined by 
the Sun Corporation at 

http : // j ava . sun. com/products/ jdk/1 . 2 /docs /guide /jvmpi/jvm 
pi . html# JVMPI_Func are all supported.) 

Events are communicated to the buffer management 
thread 3 65 (arrow 14a) via pipes or shared memory 
semaphores. The buffer management thread is responsible 
for storing the events in a buffer 355. 



In the preferred embodiment, those events which do 
not need an immediate response from the profiler agent 
are buffered and sent asynchronously to the profiler 
agent buffer receiving thread 3 56 (arrow 14b) , thus 
reducing network traffic. Some events however will have 
to be sent synchronously in order that the JVM does not 
terminate prematurely as a result of a delayed response 
from the profiler agent. 

http : //java. sun. com/products/ jdk/1 . 2 /docs/guide/ jvmpi/jvmpi .html#JVMPI_Event 

s lists supported events according to the preferred 
embodiment. Of those, JVMPI_EVENT_GC_FINISH, 
JVMP I_EVENT_GC_START , JVMPI_EVENT_ JVM_SHUT_DOWN , 
JVMPI_EVENT_THREAD_END, JVMPI_EVENT_THREAD_START require 
synchronous transmission. 

Thus the state of flows between the UJA and the 
Profiler Agent will change from asynchronous to 
synchronous and back to synchronous, depending on the 
events, interface functions and UJA controls being 
processed. When events of the synchronous type are 
received, the UJA signals to the Buffer Management Thread 
365 (arrow 14a) to flush the buffer immediately and 
transmit it to the receiving thread 356 (arrow 14b) . The 
flushed information is then communicated to the main 
thread 3 54 (arrow 14c) . The UJA and the JVM will 
henceforth wait synchronously for the agent to respond. 
The state will stay synchronous until a UJA control for 
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asynchronous transmission is received from the profiling 
agent thread . 

For asynchronous transmission, when the buffer 
reaches a pre-determined threshold or when requested to 
by the profiler agent, the UJA signals to the thread 3 65 

(arrow 14a) to transmit the buffer (arrow 14b) to the 
receiving thread 3 56 and then on to the main thread 354 

(arrow 14c) . 

Note, the data transmitted between thread 3 65 and 
thread 3 56 is compressed before transmission. It will be 
appreciated that the JVM may generate a large number of 
events and that both the buffering and data compression 
stop the network from being overwhelmed. 

It will be apparent that events can be generated by 
multiple threads (not shown) in the JVM, but are always 
received by the main JVM thread 3 20 which has loaded the 
UJA. This effectively marshals data from any active 
threads into a single thread (UJA 350) . State changes 
from asynchronous to synchronous buffer transmission 
therefore apply to ALL running JVM threads . 

Note, the flow of data and events from the UJA to 
the profiling agent can alternatively be completely 
synchronous . The completely synchronous mode is to 
assist in testing by providing deterministic behaviour. 
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It requires flows between the remote profiler and the JVM 
for every interface function and event, and therefore has 
lower performance and greater data perturbation than the 
mixed mode of asynchronous /synchronous transmission. 

Note, data is sent by a write () function in the UJA 
buffer manager thread when one of the conditions to 
trigger buffer transmission occurs if running in 
asynchronous mode, or immediately if running 
synchronously. The remote profiler data receiving thread 
retrieves buffer data with a read ( ) function. 

The performance tool 34 0 receives data regarding 
these events from the main profiler agent thread 3 54 via 
arrow 16 and also communicates in the reverse direction 
with thread 3 54. The purpose and content of all 
transmitted data will be explained with reference to 
figure 6a. 

Figure 5a shows the operation of the universal JVMPI 
adapter according to a preferred embodiment of the 
present invention and should be read in conjunction with 
figure 4 . 

The JVM 320 is launched with the command '"java 
-XrunUJA" (where UJA is the name of the adapter 3 50) . 
The UJA includes the JVM_OnLoad{) entry-point and by 
default, the command will register the UJA with the JVM 
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through this method {step 4 00) . The UJA obtains a 
function call interface by issuing a GetEnv call on the 
JavaVM pointer (step 410) and the JVMPI is then 
initialized (step 420) . Thus it can be seen that the UJA 
offers some of the basic functionality of a profiler 
agent of the prior art. In the preferred embodiment the 
notifyEvent function, JVM_Onload entry-point code, and 
the GetEnv and JVMPI interface initialisation 
functionality have all been transferred to the UJA. 

The UJA and the remote profiling tool communicate 
using a connection-oriented protocol and in the preferred 
embodiment they correspond to a TCP/IP server and client 
respectively. TCP/IP service is facilitated via 
endpoints, known as sockets. A socket comprises the 
host's IP address, along with a 16 bit number, called a 
port, and communication takes place between a socket 
running on the server and one running on the client . The 
colon delimiter may be used with the -Xrun command in 
order to specify additional options and one of these may 
be the port number. For example 

-XrunUJA:address=<port#> . The UJA starts a socket server 
with a socket 0 function (step 430) and then binds the 
TCP port number specified with address=<port#> (eg 8000) 
using a bindO function (step 440) . 

Further, the initialization of the UJA includes 
starting the buffer management thread (step 445) . This 
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is incorporated in order to minimise network traffic and 
provide for a more efficient solution. It communicates 
through signals with the UJA. 

The UJA listens on the port to which it has bound 
using a listen {) function (step 450) and waits for the 
remote profiler agent to issue a connect ( ) (step 460) . 
Until this is received the UJA waits blocked on an 
accept {) function (step 465) and continues listening on 
the port. As soon as a connect () is detected, the UJA 
can establish a connection with the remote profiler agent 
(step 470) and receive data/requests from the profiler 
agent via a readO function (step 480) and send responses 
via a write functionO (step 490). 

Figure 5b shows the operation of the profiler agent 
according to a preferred embodiment of the present 
invention and should be read in conjunction with figures 
4 and 5a . 

The profiler agent is started at step 500 with the 
command "Myprofiler -attach <hostname> : <port#> . The 
hostname identifies the computer upon which the JVM and 
UJA are running, and the port is the same as the one 
specified at UJA start-up. 

The profiler opens a socket using a socket ( ) 
function (step 510) and verifies whether the UJA is 
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running on the remote machine (step 520) . If not, the 
profiler agent waits until it detects the UJA' s presence. 
It then connects to the UJA' s server socket using the 
connect {) function with hostname and port number provided 
at client profiler agent start-up (step 530) . Once a 
connection has been established established, the UJA can 
accept requests (ie the accept () function is no longer 
"blocked") . The profiler sends such requests via a 
write 0 function (step 540), and receives replies with a 
readO function (step 550). 

Figure 6a is a flowchart of the data exchange that 
takes place between the UJA and the profiler agent 
according to a preferred embodiment. In other words, the 
diagram expands upon steps 480 and 490 of figure 5a and 
steps 54 0 and 55 0 of figure 5b. It should be read in 
conjunction with figure 4. 

Once a connection has been established between the 
profiler agent and the UJA, the profiler agent transmits 
controls via control data packets to the UJA in order to 
control its operation at step 600. These are accepted by 
the UJA at step 610. 

According to the preferred embodiment, the structure 
of control data packets are of big-endian format. They 
are also similar to those defined by Sun Corporation in 
the Java Debug Wire Protocol (JDWP) at 
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http: //java. sun. com/ j2se/l. 3 /docs/guide/ jpda/jdwp- spec. ht 
ml . Some key differences however are that the UJA 
control packet flows are synchronous and that they do not 
have to be paired with unique id fields (the id field is 
though provided for other purposes - see later) . The 
layout of the these packets is shown with reference to 
figure 6b. 

A header 700, consists of a length field 705 which 
is 4 bytes long. This indicates the length of the whole 
packet, which according to the preferred embodiment is a 
minimum of 10 bytes. An id field 710 (4 bytes) contains 
a unique identifier which can be set by the originator of 
the control. If set, it will be echoed (within a 
response field (see later) forming part of a header 
pre-pended to all responses) on all responses to the 
control and event data generated as a result of the 
control. The unique identifier can then be used for 
tracking purposes . 

A flag 720 (1 byte) signals state change between the 
UJA and the remote profiler agent. According to the 
preferred embodiment, 0x81 is used to switch event flow 
to synchronous transmission and 0x82 to switch the flow 
to asynchronous. A command field 730 (1 byte) contains a 

hexadecimal value corresponding to a command number. 
Preferably these are as follows: 
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1 - Query UJA version 

2 - Query JVM version 

3 - Query JVMPI version 

4 - Query target platform operating system and level 

5 - Query target platform hardware 

6 - Query target platform RAM amount 

7 - Query target system endianness 

10 - Define transmission state, synchronous or 
asynchronous 

12 - Define trace buffer length 

13 - Define trace buffer operation 

14 - Define data compression format 

15 - Define the event data to be returned to the tool 

16 - Undefine the event data 

17 - Transmit the data buffer contents 

2 0 - Detach from JVM 

3 0 - Terminate JVM 

100 - 126 - interface functions 

Note, the each value is actually stored as a hexadecimal 
value within the one byte response field, but has been 
listed in decimal for ease of understanding. 

Finally there is a data field 74 0 of variable 
length. This may contain data indicating the length of 
the trace buffer, the data compression format etc. 

As can been seen from the commands listed above 
there are controls for turning data compression on or 
off, requesting UJA environment specific data, and 
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determining whether all JVM events are to be transmitted 
synchronously to the remote profiling agent from the UJA, 
or whether they should be batched and sent 
asynchronously. A further control is used to ensure that 
each JVMPI event has a 64 -bit high resolution timestamp 
added to it. This allows the profiling tool to provide 
accurate timing information in its subsequent analysis, 
and interleave events received from multiple JVMs being 
profiled . 

The size of a buffer to be used by the UJA is also 
specified via a control, along with various buffer 
actions. Note, controls can be sent at anytime and not 
just at startup. Thus they can also include: start 
tracing; stop tracing; transmit buffer to client; 
circular buffer wrap; stop tracing when buffer full; and 
transmit when GC START event received. Typically, the 
contents of the buffer are transmitted to the remote 
agent when filled; when requested by the tool; or at JVM 
shutdown . 

In response to the request for UJA environment 
specific data by the profiler agent, the UJA queries this 
information and transmits it at step 620. In the 
preferred embodiment, this includes: UJA version number; 
target JDK level; target JVMPI level; target platform 
hardware; target platform operating system & level; 
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target system RAM; and target system "Endianness" (Note, 
the default is big endian / network byte order) . 

The profiler agent will also receive appropriate 
responses (step 62 0) from the UJA. These can include 
data conventions used by the measured JVM - pointer size, 
byte ordering, bit ordering, string encoding - and 
additional responses such as whether the control packet 
header was ok or not, the length of following data, an 
indication that the JVM is terminating etc. Note, the 
layout of a response data packet is virtually identical 
to that of a control packet and is shown with reference 
to figure 6c. If set in the corresponding control data 
packet, then the id field 810 echoes the unique 
identifier in corresponding control packets. A flag 
field 820 uses the same hexadecimal values as those used 
by a control packet to switch between synchronous and 
asynchronous transmission. Additionally however, 0x8 0 is 
used to indicate that this packet contains a response. 
Moreover, instead of a command field 73 0 there is a 
response field 83 0 (1 byte) . According to the preferred 
embodiment, this contains a value corresponding to one of 
those listed below: 

0 - command processed without error 

110 - Invalid transmission state requested 

112 - Invalid trace buffer length requested 

113 - Invalid trace buffer operation requested 

114 - Invalid data compression format requested 
112 - VM_DEAD 
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123 - invalid UJA command 

2 55 - fatal error, UJA terminating 

Note, the each value is actually stored as a hexadecimal 
value within the one byte response field, but has been 
listed in decimal for ease of understanding. 

Once again there is also a data field 840 of 
variable length. This contains the information requested 
by a corresponding control. For example, in response to 
a command, 'Query JVMPI version', int jvmpiVersion will 
be returned. This is the JVMPI version number as returned 
from JVMPI interface version function ( ' j int version' - 

see http://j ava . sun . com/product s / j dk/ 1 . 2 /docs / gui de / j vmpi / j vmpi . html #>JVMPI_Func ) ) 

The exchange of controls and receipt of UJA 
responses and data by the profiler agent prepare both 
ends for event requests etc. In the preferred 
embodiment, the UJA supports all the events that the JVM 
it is attached to provides. 

Remote JVMPI interface and event functions can now 
start to be processed. The interface functions are 
bidirectional initiated, and in most cases are run 
synchronously by the UJA between the JVM and the 
profiling agent. 

The remote tool invokes an interface function by 
sending a UJA control packet specifying the appropriate 
interface command number, and where required, the 
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necessary data that function requires in the control 
packet data field. Appendix C lists each interface 
function and its corresponding command number. 

5 The UJA performs the function requested, and returns 

updated or requested data as required. Note that the 
void (*NotifyEvent) (JVMPI_Event *event) is already 
implemented by the UJA on behalf of the remote tool, so 
is not required. The call -back from the JVM to the 
10 profiling agent occurs in the UJA, not the remote tool - 

the remote tool logic processing handles events passed 
from the UJA buffer manager thread. 

To aid comprehension, an example of the control 
15 packet used to enable the profiler agent to request to be 

sent the thread CPU time, and the corresponding response 
containing a value of 285010 nanoseconds: 



UJA control packet 



Header 

length 10 (4 bytes) 

id XXX (4 bytes) 

flag 0x81 (1 byte) 

command 0x70 (1 byte) 

( No data ) 



UJA response packet 
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Header 



Length 26 
id XXX 
flag 0 
response 0x8 0 
Time stamp nnnnnnnn 



( 4 bytes ) 
( 4 bytes ) 
( 1 byte ) 
( 1 byte ) 
( 8 bytes ) 



Data 



00285010 



{ 8 bytes ) 



10 



20 



25 



As previously mentioned with reference to figure 4, 
events are transmitted to the profiler agent over a 
second connection consisting of a link between the buffer 
management thread and the profiler buffer receiving 
thread. Referring again to figure 6a, to enable this at 
step 625, the UJA spawns the buffer management thread. 
The profiler agent also spawns the profiler buffer 
receiving thread 356. Thread 356 opens a socket server 
on an agreed port number, and the buffer management 
thread connects to it {step 627) . As previously 
mentioned, it is over this second connection that event 
data is sent. Two connections are established so that 
neither event data nor control data is interrupted by the 
other. (Note, steps 625 and 627 are not referenced in 
Appendix B . ) 

At step 630, the remote profiler agent 254 enables 
event notif iciation of all events that the JVM generates 
which it is interested in. In the example given in 
Appendix B, this is achieved via 

j vmpi_interf ace - >EnableEvent ( JVMPI_EVENT_CLASS_LOAD , 
NULL) and only the JVMPI_EVENT_CLASS_LOAD events (ie the 
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loading of a new java class) are of interest. Note, 
specific event types can be requested at any time over 
the first connection. 

5 The profiler agent then informs the UJA of these 

events at step 640 (event- >u . class_load . class_name ; ) . To 
achieve this, the profiler agent wraps the enabling class 
load event type notification code with a UJA header and 
issues a write () to its socket connection to transmit to 
10 the UJA. It will be appreciated that a control packet is 

used with ^15' contained within the command field. The 
particular event name is contained within the data field. 
Event types may also be specified during initialisation 
(ie step 600) . 

15 

The UJA communicates the received information to the 
JVM { jvmpi_interface->EnableEvent ( JViyiPI_EVENT_CLASS_LOAD, 
NULL) ) and then verifies to see whether the requested 
event notification is accepted by it (step 650) . If not, 
20 the UJA returns a status of "not okay" to the profiler 

agent (step 660) and the agent can then request the same 
event again or a new type (step 640) . Alternatively, the 
agent can do nothing but wait for previously enabled 
events (not shown) . 



If the event type is accepted, then the UJA returns 
a status of "okay" to the profiler agent and subsequently 
waits for callback by the JVM of the requested event 
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(step 680) . When this is received, the UJA determines 
whether a synchronous transmission is required to the 
profiler agent (step 685) . If so, the buffer management 
thread is signalled to flush the buffer (686) and 
transmit it to the profiler agent (step 690) over the 
second connection. The information is then 
processed/stored as appropriate (step 710) . (Such events 
will typically cause the profiler agent to respond 
forthwith to the JVM.) Otherwise the details are written 
to the buffer (step 6 95) for asynchronous transmission. 
In the preferred embodiment, the buffer management thread 
checks to see whether this triggers a buffer send by 
going over a pre-determined threshold (step 700) and if 
not, waits for call back regarding subsequent events 
until a buffer send is triggered. Otherwise, the buffer 
manager thread transmits the buffer to the profiler agent 
at step 710. This is received by the profiler agent 
buffer receiving thread and is then the data is processed 
/ stored as appropriate (step 720) . 

Note, preferably the format of the data sent by the 
buffer is as follows: 

length (4 bytes) - this includes a total calculated from 
the length, and id , (see below) , and 
also from the length of the event data 
contained within the char field (see 
below) ; 
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id (4 bytes) - this is the unique id sent by the profiler 
agent when it issued command 17 via a 
control packet; 

char - buffered event data. Repeated instances of UJA 
response packets . 

If for example, the remote profiler requests to be 
informed whenever the JVM loads a new java class 
(u. class_load. class_narae) , the name of the loaded class 
is required from the UJA by the profiling agent . Thus 
the field char in the buffer will contain a complete UJA 
response packet with the header fields and the contents 
of class_name in the data field. 

This layout is repeated for subsequent events. 
Furthermore, if a compression algorithm has been 
requested, this will be applied to the whole buffer just 
before transmission. 

Note, the profiler agent may continue to receive 
both individual and buffered events until the JVM 
terminates. At termination, the UJA informs the profiler 
agent via a response that the JVM is shutting down. A 
close function 0 then shuts both the UJA and profiler 
agent sockets' , and thus the connection is broken. 

It will be appreciated that the UJA may transmit 
data/responses at anytime during processing either on its 
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own initiative or at the request of the profiler agent. 
Likewise, the profiler agent may at anytime request 
notification of new events, disablement of certain event 
notifications etc. 

The UJA provides a generic interface to the profiler 
agent which is remotely accessible as opposed to the 
proprietary interfaces typically used in client/server 
profiling tools. It is envisaged that the UJA will 
typically be provided by the JVM supplier for each 
specific platform. Thus performance tool vendors need 
only modify the profiler agent once to interact with the 
UJA over the network, rather than having to port their 
agent to multiple platforms. In other words, this one 
modification will then allow their tool to operate in 
conjunction with a JVM on any platform for which a UJA is 
available. At the same time, the tools vendor is relieved 
of any need to support their profiling agent on different 
platforms . 

This remote setup is particularly applicable to 
performance profiling those applications which execute on 
embedded systems . Such systems are invariably extremely 
limited in terms of resource. Typically, profiling tools 
perturb the performance characteristics of the system 
they are measuring. The events which the JVMPI is 
capable of generating that are of interest to performance 
tools, such as method entry and exit, occur very 
frequently and can accumulate high data volumes. The 
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processing of such data is resource hungry. 
Additionally, many 3rd party tools offer 'real time' 
visualization of Java performance data as it is being 
generated. If the computer being measured is the same 
one as is being used to display the data, the 
perturbation of the data can be quite considerable. This 
is not such a problem with the powerful desktop machines, 
but can really overwhelm a resource constricted system. 

In order to interact with the UJA, a standard 
profiling agent may be modified to include a bolt-on 
front-end component (not shown) . This would, for 
example, be responsible foi- setting xvp communications 
between the agent and the UJA and for transmitting data 
between the two. Additionally, it would amongst other 
things, receive events and perform decompression of data 
where necessary. Furthermore, it would process the time 
stamping such that buffered events would be fed in a 
quasi -synchronous manner to the main prof x ling agent, as 
if it were located on the same system as the JVM itself 
(obviously this would have to be subject to some fixed 
network delay) . 

Alternatively the profiling agent could be modified 
to natively support the UJA. In other words, to work 
directly with buffered events etc. Although this would 
be more time-consuming initially, it would offer greater 
flexibility in the long run. 



GB9-2000-0047-US1 



37 



Finally, it will be apparent to a person skilled in 
the art that although the profiler agent and the 
performance tool are shown as running on the same 
computer, the invention is not limited to such. Rather, 
the profiler agent may receive events from the UJA and 
then communicate information based on these events to a 
performance tool running on a remote machine . 
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include <jvmpi.h> 



// global jvmpi interface pointer 
static JVMPI_Interf ace * j vmpi_interf ace ; 



// function for handling event notification 
void notifyEvent ( JVMPI_Event *event) { 
switch (event ->event_type) { 
case JVMPI_EVENT_CLASS_LOAD: 

fprintf {stderr, "myprofiler> Class Load : %s\n" , 
event - >u . class_load . class_name) ; 
break; 

} 

} 

// profiler agenc entry point 
extern "C" { 

JNIEXPORT jint JNICALL JVM_OnLoad ( JavaVM *jvm, char *options, 
void * reserved) { 

fprintf (stderr, "myprofiler> initializing \n" ) ; 

// get jvmpi interface pointer 

if ( (jvm->GetEnv ( (void **) &jvmpi_interface, JVMPI_VERSI0N_1) ) 

< 0) { 

fprintf (stderr, "myprof iler> error in obtaining jvmpi 
interface pointer\n" ) ; 
return JNI_ERR; 



// initialize jvmpi interface 
jvmpi_interface->NotifyEvent = notifyEvent; 

// enabling class load event notification 

jvmpi_interface->EnableEvent (J\T4PI_EVENT_CLASS_LOAD, NULL) ; 

fprintf (stderr, "myprof iler> .... ok \n\n" ) ; 
return JNI_OK; 

} 
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Appendix A: the source code for a simple profiler agent provided by 
Sun Microsystems . 
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// New High level UJA logic 
// open a socket 
// bind to a port 

// start the buffer manager thi'ead 

// listen on that port for remote tool requests 

// start a buffer manager thread 

// establish connection with remote tool 

II accept UJA controls for data transmission, buffer controls el 

// provide UJA data as requested on details of local system 



/ / New High level remote tool logic 
// open a socket 

// connect to the host, port used of the UJA 
// exchange UJA controls and data with the 
// UJA sufficient to prepare the tool and UJA 
// for event requests 

// Existing Low level remote tool logic 



// enabling class load event notification 

jvmpiJnterface->EnableEvent(JVMPI_EVENT_CLASS_LOAD.NULL); 

// tell the UJA what event data the remote tc 
// is interested in 
event->u.class_load.class_name; 

// New High level remote tool logic 

// wrap enabling class load event notificatio 
// code with UJA wrapper / header 
// issue write () to its socket connection to 
// transmit to the UJA 



// New UJA low level logic 

// issue the JVMPI_EVENT_CLASS_LOAD, NULL enable event as local p 
// enabling class load event notification 

jvmpi_interface->EnableEvent(JVMPI_EVENT_CLASS_LOAD,NULL); 
// High level UJA logic 

II check requested event has been accepted by the local JVM 
// return an OK / not OK response to the remote tool 



// High level UJA logic 

// Callback received by UJA for a requested event 
// Write details of data for that event that the tool 
// requested to UJA buffer. 

// If this ti-iggers a bulfer-send by going over a thi'eshold, 
// signal the buffer manager thi'ead to ti-ansmit the buffer 



// check event request has been processed 
//OK by UJA 
//wait for UJA buffer tr 



// receive UJA buffer 

// process / store buffer data as required 



B: a pseudo code representation of the functionality supported by both the 
UJA and the remote profiler agent according to a preferred embodiment of the 
present invention. 
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UJA 

command 
number 



/* interface functions */ 
typedef struct { 

100 jint version; /* J VMPI version */ 

/* interface implemented oy the profiler */ 

void (*NotifyEvent)(JVMPl_Event *event); 
/* interface implemented by the JVM */ 

101 jint (*EnableEvent)(jint event_type, void *arg); 

102 jint (*DisableEvent)0'int eventjype, void *arg); 

103 jint (*RequestEvent)(jint event_type. void *arg); 

1 04 void (*GetCallTrace)(JVMPr_CallTrace *trace, jint depth); 

105 void (*ProfilerExit)0"int); 

106 JVMPI_RawMonitor (*RawMonitorCreate)(char *lock_name); 

1 07 void (*RawMonitorEnter)(JVMPI_RawMonitor lockjd); 

108 void (*RawMonitorExit)(JVMP]_RawMomtor lockjd); 

109 void (*RawMonitorWait)(JVMPI_RawMonitor lock_id, jlong ras); 

1 10 void (*RawMonitorNotifyAll)(JVMPI_RawMonitor lockjd); 
! 1 1 void (*RawMonitorDestroy)(JVMPl_RawMonitor lockjd); 

1 1 2 jlong (*-GetCmTentThi-eadCpuTime)(void); 

1 1 3 void (*SuspendThi-ead)(JNIEnv *env); 

1 14 void (*ResumeThi-eadXJNlEnv *env); 

115 jint (*GetThreadStatas)(JNIEnv *env); 

1 1 6 jboolean (*ThreadHasRun)(JNIEnv *env); 

117 j int (*CreateSy stemThread)(char *name, jint priority, void (*f)(void *)); 

1 1 8 void (*SetnireadLocalStorage)(JNlEnv *env Jd, void *pti-); 

1 1 9 void * (*GetThreadLx)calStorage)(JNIEnv *env Jd); 

120 void (*DisableGC)( void); 

121 void (*EnableGC)( void); 

122 void (*RunGC)(void); 

123 jobjectID (*GetThreadObject)(JNIEnv *env); 

124 jobjectID (*GetMethodClass)(jmethodlD mid); 

125 jobject (*jobjecttD2jobject)0objectlDjid); 

126 jobjectID (*jobject2jobjectID)(jobject j); 



} JVMPIJnterface; 

Appendix C : the interface as defined by the Sun Corporation between the profiler 

agent and the JVM, along with the corresponding command number to enable 
the profiler agent to invoke each listed function according to a 
preferred embodiment of the present invention. 
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CLAIMS 

1. Apparatus for providing application execution data 
to a profiling agent on a remote system as requested by 

5 said agent, wherein a first application local to said 

apparatus generates said application execution data, said 
apparatus compr i s ing : 

means for receiving a request via a network 
interface from said profiling agent for said application 
10 execution data; 

means, responsive to said request, for requesting 
said application execution data from said first 
' application via a local interface; 

means for receiving said application execution data 
15 from the first application via said local interface; and 

means, responsive to receipt of said application 
execution data, for transmitting said application 
C3 execution data to the profiling agent via said network 

interface . 

V :2 0 

2 . The apparatus of claim 1 wherein said network 
interface exposes substantially all the functionality of 
the local interface to a profiling agent on a remote 
system . 



3 . The apparatus of claim 2 wherein said network 
interface further allows receipt of controls from said 
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profiling agent for conbrolling the operation of said 
apparatus . 

4 . The apparatus of claim 3 , wherein at least one of 
said controls provides for selectively switching between 
synchronous and asynchronous transmission of said 
application execution data to said profiling agent. 

5 . The apparatus of claim 3 , wherein said controls are 
transmitted over a first connection, and said application 
execution data over a second connection. 

6. The apparatus of claim 1, further comprising a 
buffer for storing said application execution data prior 
to transmission to said profiling agent. 

7. The apparatus of claim 6, wherein said application 
execution data comprises events, and each buffered event 
includes a tiraestamp. 

8. The apparatus of claim 7, wherein at least one of 
said events is specified as synchronous, and said 
apparatus comprises means, responsive to receipt of a 
synchronous event, for switching to synchronous 
transmission of said application execution data. 



9. The apparatus of claim 1 comprising: 
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means for compressing said application execution 
data, prior to transmitting said application execution 
data to said profiling agent. 

10. The apparatus of claim 1, wherein said local 
interface is a java virtual machine profiling interface 
and said first application is a java virtual machine, and 
wherein a second application executes on top of said 
first application and causes said first application to 
generate said application execution data. 

11. A method for providing application execution data to 
a profiling agent on a remote system as requested by said 
agent, wherein a first application generates said 
application execution data, said method comprising the 
steps of : 

receiving a request at an apparatus via a network 
interface from said profiling agent for said application 
execution data; 

responsive to said request, requesting said 
application execution data from said first application 
via a local interface; 

receiving said application execution data at said 
apparatus from the first application via said local 
interface; and 

responsive to receipt of said application execution 
data at said apparatus, transmitting said application 



GB9-2000-0047-US1 



44 



execution data to the profiling agent via said network 
interface . 

12. The method of claim 11 wherein said network 

5 interface exposes substantially all the functionality of 

the local interface to a profiling agent on a remote 
system . 

13 . The method of claim 12 further comprising the step 
10 of : 

receiving controls from the profiling agent at said 
apparatus for controlling the operation of said 
apparatus . 

15 14 . The method of claim 13 further comprising the step 

of: 

responsive to receipt of at least one of said 
controls, selectively switching between synchronous and 
=y asynchronous transmission of said application execution 

S;2 0 data to said profiling agent. 

15. The method of claim 13 comprising the steps of .- 

transmitting the controls over a first connection; 

and 

25 transmitting said application execution data over a 

second connection. 
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16. The method of claim 11, further comprising the step 
of: 

storing said application execution data in a buffer 
prior to transmission to said profiling agent. 

17. The method of claim 16, wherein said application 
execution data comprises events, and said method 
comprises the step of: 

including a timestamp with each buffered event. 

18. The method of claim 17, wherein at least one of said 
events is specified as synchronous, said method further 
comprising the step of: 

responsive to receipt of a synchronous event, 
switching to synchronous transmission of said application 
execution data. 

19. The method of claim 11 comprising the step of: 
compressing said application execution data, prior 

to transmitting said application execution data to said 
profiling agent. 

20. The method of claim 1, wherein said local interface 
is a java virtual machine profiling interface and said 
first application is a java virtual machine, and wherein 
a second application executes on top of said first 
application and causes said first application to generate 
said application execution data. 
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21. A computer program product comprising computer 
program code stored on a computer readable storage medium 
which, when executed on a computer, performs the method 
of claim 11. 
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ABSTRACT OF THE DISCLOSURE 

The invention relates to an apparatus for providing 
event data, generated by a JVM local to the apparatus, to 
5 a profiling agent on a remote system as requested by that 

agent. A request is received at the apparatus, via a 
network interface, from the profiling agent for certain 
event data. This request is forwarded via the JVMPI to 
the JVM and the requested data is transmitted to the 
10 apparatus, as and when generated by the JVM. (The event 

data is also transmitted via the JVMPI) . The event data 
is then transmitted to the profiling agent via the 
network interface. 
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DECLARATION AND POWER OF ATTORNEY FOR 
PATENT APPLICATION 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name; I believe i 
am the original, first and sole inventor (if only one name is listed below) or an original, first and joint 
inventor (if plural names are listed below) of the subject matter which is claimed and for which a patent 
Is sought on the invention entitled 

PERFORMANCE PROFILING TOOL 

the specification of which (check one) 

X is attached hereto. 

was filed on 

as Application Serial No. 
and was amended on 



I hereby state that I have reviewed and understand the contents of the above identified specification, 
including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the patentability of this application 
in accordance with Title 37, CFR 1 .56. 

I hereby claim foreign priority benefits under Title 35, USC 1 19 of any foreign application(s) for patent 
or inventor's certificate listed below and have also identified below any foreign application for patent 
or inventor's certificate having a filing date before that of the application on which priority is claimed: 

Prior Foreign Application(s): 

0012914.8 United Kingdom 27.05.00 _X_Yes No 

Number Country Filing Date Priority Claimed 

Day/MonthA'ear 

I hereby claim the benefit under Title 35, USC 120 of any United States application(s) listed below and, 
insofar as the subject matter of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35, USC 112, I acknowledge 
the duty to disclose information material to the patentability of this application as defined in Title 37, 
CFR 1 .56 which occurred between the filing date of the prior application and the national or PCT 
international filing date of this application: 

Prior U.S. Applications: 



Serial No. Filing Date Status 



I hereby declare that all statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these statements were made 
with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful 
false statements may jeopardize the validity of the application or any patent issued thereon. 
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POWER OF ATTORNEY: As a named inventor, I hereby appoint the following attorneys and/or agents 
to prosecute this application and transact all business in the Patent and Trademari< Office connected 
therewith: 

Edward H. Duffield, Reg. No. 25,970; A. Bruce Clay, Reg. No. 32,121; Gregory M. Doudnikoff, Reg. 
No. 32,847; Jeanine S. Ray-Yarletts, Reg. No. 39,808; Jerry W. Herndon, Reg. No. 27,901, Kevin J. 
Fournier, Reg. No. 34,333 

Send all correspondence to: 



IBM Corp, IP Law Dept T81/B062. 
3039 Cornwailis Road, 
PO Box 12195, 

Research Triangle Park, NC 27709-2195. 
Telephone: (919) 



FULL NAME OF SOLE OR FIRST INVENTOR: Alan P Stevens 



INVENTOR'S SIGNATURE: 




DATE: 



RESIDENCE: 



Rozelle House, Rozelle Close, 
Hampshire S022 6QP, UK 



Littleton, Winchester, 
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